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DISCLAIMER 



• We are not « terrorists ». We won't release our 
PoC backdoor. 

• The x86 architecture is plagued by legacy. 
Governments know. The rest of the industry : 
not so much. 

• There is a need to discuss the problems in 
order to find solutions... 

• This is belived to be order of 11 1 111J I 



magnitudes better over existing 
backdoors/malware 




EXPLICIT CDNTEN1 



Agenda 



• Motivation : state level backdooring ? 

• Co re boot & x86 architecture 

• State of the art in rootkitting, romkitting 

• Introducing Rakshasa 

• Epic evil remote carnal pwnage (of death) 

• Why cryptography (Truecrypt/Bitlocker/TPM) 
won't save us... 

• Backdooring like a state 



Could a state (eg : China) backdoor 
all new computers on earth ? 

■ Occupying the Information High 
Ground: 
Chinese Capabilities for Computer 
Network Operations and 
Cyber Espionage 

This close relationship between some of China's— and the world's— largest 
telecommunications hardware manufacturers creates a potential vector for state sponsored 
or state directed penetrations of the supply chains for microelectronics supporting U.S. 
military, civilian government, and high value civilian industry such as defense and 
telecommunications, though no evidence for such a connection is publicly available. 




A bit of x86 architecture 



State of the art, previous work 



Previous work 



Early 80s : Brain virus, targets the MBR 

80s, 90s : thousands of such viruses 

2007, John Heasman (NGS Software) Blackhat US: 
backdoor EFI bootloader 

2009, Anibal Saco and Alfredo Ortega (Core security), 
CanSecWest : patch/flash a Pheonix-Award Bios 

2009, Kleissner, Blackhat US : Stoned bootkit. Bootkit 
Windows, Truecrypt. Load arbitrary unsigned kernel 
module. 

2010, Kumar and Kumar (HITB Malaysia) : vbootkit 
bootkitting of Windows 7. 

Piotr Bania, Konboot : bootkit any Windows (32/64b) 
2012 : Snare (Syscan) : EFI rootkittinq 



DEMO : Bootkitting Windows 



Introducing Rakshasa 



Goals : create the perfect backdoor 



• Persistant 

• Stealth (virtually undetectable) 

• Portable (OS independant) 

• Remote access, remote updates 

• State level quality : plausible deniability, non 
attribution 

• Cross network perimeters (firewalls...) 

• Redundancy 



Rakshasa : design 



• Core components : 

Co re boot 
SeaBios 
iPXE 
payloads 

Built on top of free software : portability, non 
attribution, cheap dev (~4 weeks of work), 
really hard to detect (without false positives). 

• Payload : Reverse Engineered/Refactored 
konboot payload (2 days of work). 



Rakshasa 



• Flash the BIOS (Coreboot + PCI roms such as 
iPXE) 

• Flash the network card or any other PCI device 
(redundancy) 

• Boot a payload over the network (bootkit) 

• Boot a payload over wifi/wimax (breach the 
network perimeter, bypasses network detection, 
l(P|D)S ) 

• Remotely reflash the BIOS/network card if 
necessary 



Rakshasa : embedded features 



• Remove NX bit (from BIOS or PCI) 
— > executable heap/stack. 

• Remove CPU updates (microcodes) 

• Remove anti-SMM protections (=>local root) 

— > Permantent lowering of the security level on 
any OS. Welcome back to the security level of 
1999. 

— > Persistant, even if HD is remove/restored. 

Optionally : Disable ASLR (bootkitting) by 
patching the seed in kernel land on the fly on 
Windows. 



Rakshasa : remote payload 



• Bootkit future OSes 

• Update/remove/reflash firmwares (PCI, BIOS) 

• Currently capable of Bootkitting any version of 
Windows (32b/64b) 

• Use a minimal linux initrd in case we want to 
mount/modify the filesystem (/etc/shadow on 
any UNIX like, add new account with ADMIN 
privileges on Windows, enable remote desktop 
- possibly enable dual remote desktop on 
Windows XP Pro by patching 2 dlls...) 



Rakshasa : stealthness 



• We don't touch the disk. evidence on the 
filesystem. 

• We can remotely boot from an alternate 
payload or even OS : fake Truecrypt/Bitlocker 
prompt ! 

• Optionally boot from a WIFI/WMAX stack : 
network evidence on the LAN. 

• Fake BIOS menus if necessary. We use an 
embedded CMOS image. We can use the real 
CMOS nvram to store encryption 
keys/backdoor states between reboots. 



Rakshasa : why using 
Coreboot/SeaBios/iPXE is the good 

approach 

• Portability : benefit from all the gory reverse 
engineering work already done ! 

• Awesome modularity : embbed existing 
payloads (as floppy or cdrom images) and PCI 
roms directly in the main Coreboot rom ! 

Eg : bruteforce bootloaders (Brossard, H2HC 
2010), bootkits without modification. 

• Network stack : ip/udp/tcp, dns, http(s), tftp, 
ftp... make your own (tcp over dns? Over ntp ?) 



PCI rom from scratch (asm) 

section .text 



Bios expension ROM header 



db 0x55 ; Signature 
db Oxaa ; Signature 

db 1 7 ; number of sectors 

start: 



DEMO : Evil remote carnal pwnage 

(of death) 



I can write blogs too... Muhahahaha. 



DEMO : Evil remote carnal pwnage 

(of death) 



I can write blogs too... Muhahahaha. 



How to properly build a botnet ? 



• HTTPS + assymetric cryptography (client side 
certificates, signed updates) 

• Fastflux and/or precomputed IP addresses 

If Microsoft can do secure remote updates, so 
can a malware ! 

• 

Avoid DNS take overs by law enforcement 
agencies by directing the C&C rotatively on 
innocent web sites (are you gonna shut down 
Google.com?), use assymetric crypto to push 
updates. 



Why crypto won't save you... 



Why crypto won't save you. 



• We can fake the bootking/password prompt by 
booting a remote OS (Truecrypt/Bitlocker) 

• Once we know the password, the BIOS 
backdoor can emulate keyboard typing in 16b 
real mode by programming the 
keyboard/motherboard PIC microcontrolers 
(Brossard, Defcon 2008) 

• If necessary, patch back original 
BlOS/firmwares remotely. 



DEMOS 



How about Avs ?? 



Putting an AV on a server to protect against 
unknown threats is purely cosmetic. 

You may as well put lipstick on your servers.. 



Example : 3 years old bootkit 
f) irustotal 



SHA256: 


214ce3ce21e3&ea145ba2cd52cce7e94367a2701ea5f4efda4a1cc248fbec1d2 






File name: 


konFLOPPY.img 






Detection ratio: 


2/ 43 








Analysis date: 


2012-03-07 07:14:43 UTC ( 3 weeks, 3 days ago ) 







Kaspersky 




20120307 
20120307 


McAfee 




McAfee-GW-Edition 


Heu ri st ic . Beh aves Li ke. Ex ploit . CodeE xec . E P M G 


20120307 


Microsoft 




20120307 


NOD32 




20120307 


Worm an 


nown virus. B.H 


20120304 
20120306 


n Protect 





Example : 3 years old bootkit (+ 
simple packer) 




Realistic attack scenarii 



Realistic attack scenarii 



• Physical access : 

Anybody in the supply chain can backdoor your 
hardware. Period. 

Flash from a bootable USB stick (< 3mins). 

• Remote root compromise : 
If (OS == Linux) { 

flash_bios; 

} else { 
Pivot_over_the_MBR ; 

} 



Realistic attack scenarii 




BONUS : Backdooring the 
datacenter 



Remediation 



Remediation (leads) 



• Flash any firmware uppon reception of new hardware with 
open source software 

• Perform checksums of all firmwares by physically 
extracting them (FPGA..) : costly ! 

• Verify the integrity of all firmwares from time to time 

• Update forensics best practices : 

1) Include firmwares in SoW 

2) Throw away your computer in case of intrusion 

Even then... not entirely satisfying : the backdoor can flash 
the original firmwares back remotely. 



Side note on remote flashing 

• BIOS flashing isn't a problem : the flasher 
(Linux based) is universal. 

• PCI roms flashing is (a bit of) a problem : 
vendor dependant... 



Detecting network card 
manufacturer from the remote C&C 



File Frtit yiew History Bookmarks Tools Holp 




<£i A & ipxe.org - g) |.'|- ipxe 




Most Visited" flasks Half lirowr ML'jJU.^ (f; HL'j o-ga My be* Linux;iJtib system _.. Reverse IP Lookup ... ;;;; http://www.zor.abat... — http://www.mgid.ee... ;;;; 1 he Art of Assembly... QDLI CON© -IS Hack... :; Jee destruction Mb 


Dynamic scripts 




An iPXE script does not have to be a static text file. For example, you could direct iPXE to boot from the URL 




http :// 192. 168.0. 1/boot . php?mac=${net0/mac}&asset=${asset ; urist ring} 




which would expand to a URL such as 




http : //192 .168.0. 1/boot . php?mac=52 : 54 : OG : 12 : 34 : 56&asset=BKQ42Ml 





The boot.php program running on the web server could dynamically generate a script based on the information provided in 
the URL. For example, boot.php could look up the asset tag in a MySQL database to determine the correct iSCSI target to 
boot from, and then dynamically generate a script such as 



#! ipxe 

set initiator-iqn iqn.2010-04.org. ipxe: BKQ42M1 

sanboot iscsi : 192 . 168 .0. 20: :::iqn.2G10-04.org. ipxe: winxp 

For the sake of backwards compatibility, iPXE will also recognise legacy gPXE scripts starting with the magic line #!gpxe. However, 
gPXE is not capable of running iPXE scripts, since the iPXE script language is substantially more advanced than the gPXE script 
language. 

scripting.txt ■ Last modified: 2011/12/02 21:36 by mcb30 



Login 



Search 



Backdooring like NSA China 



Backdooring like a state 



Rule #1 : non attribution 

- you didn't write the free software in first place. 

- add a few misleading strings, eg : in mandarin ;) 

Rule #2 : plausible deniability 

- use a bootstrap known remote vulnerability in a 
network card firmware 

(eg : Duflot's CVE-2010-0104) 

— > « honest mistake » if discovered. 

- remotely flash the BIOS. 

- do your evil thing. 

- restore the BIOS remotely. 
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Questions ? 



